FYI we're looking at introducing a sql_mode yml config option here and so it might be worth using that instead:
silverstripe/silverstripe-framework#9721

It would mean that you need Silverstripe 4.7 to support MySQL 5.7, though.

Alternatively, fluent could be patched to not use invalid queries. Notably, that would mean that fluent works with PostgreSQL (I imagine that it's broken at the moment)

Something that is also a little confusing to me is how the tests are currently passing, when they already run on MySQL 5.7. Is that because the test suite doesn't cover the broken functionality? In that case, it might be valuable to cover it with a test.

It's not so much that fluent is generating incorrect queries (at least not anymore), it's more that there's always been a SQL surface area that could trigger this error.

The specific issue due to sort #257 was fixed since then, but I'm aware there are still situations where manual queries can still get trapped.

Fluent does rely on users being super careful when writing queries (i.e. you pretty much MUST use "Table"."Column"), but in practice we have to accept that hand crafted SQL may not always be that precise. This patch is more to soften the blow of these cases, rather than guarantee that no invalid queries ever reach the DB.

That's the trouble with using raw SQL strings as a query representation. :P

Ah, right. Maybe it does work on PGSQL then... (I just commented suggesting it wouldn't on the other PR)

I actually built fluent originally on postgres, then worked backwards to mysql. ;P